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ABSTRACT 

We address the problem of scaling authentication for nam¬ 
ing, routing, and end-entity certification to a global environ¬ 
ment in which authentication policies and users’ sets of trust 
roots vary widely. The current mechanisms for authenti¬ 
cating names (DNSSEC), routes (BGPSEC), and end-entity 
certificates (TLS) do not support a coexistence of authenti¬ 
cation policies, affect the entire Internet when compromised, 
cannot update trust root information efficiently, and do not 
provide users with the ability to make flexible trust deci¬ 
sions. We propose a Scalable Authentication Infrastructure 
for Next-generation Trust (SAINT), which partitions the In¬ 
ternet into groups with common, local trust roots, and iso¬ 
lates the effects of a compromised trust root. SAINT re¬ 
quires groups with direct routing connections to cross-sign 
each other for authentication purposes, allowing diverse au¬ 
thentication policies while keeping all entities globally veri¬ 
fiable. SAINT makes trust root management a central part of 
the network architecture, enabling trust root updates within 
seconds and allowing users to make flexible trust decisions. 
SAINT operates without a significant performance penalty 
and can be deployed alongside existing infrastructures. 


1. INTRODUCTION 


Alice lives in the Republic of Mythuania and frequently trav¬ 
els around the world for business purposes. In her business 
dealings, she frequently communicates with her clients and 
with her banks, which are located all over the world. Eor the 
security of these communications to client and bank web¬ 
sites, Alice primarily relies on three mechanisms; DNSSEC Q 
to authenticate name-to-address mappings in DNS records, 
RPKI and BGPSEC ^ |28l to authenticate routes used to 
reach the sites, and TLS 1151 to authenticate the public keys 
used to establish a confidential connection to the sites. These 
mechanisms rely on trust roots, which are assumed to be 
trustworthy, and follow one of two models: monopoly (the 
entire system has a single trust root) and oligarchy (users 
configure many trust roots of equal authority). 

Unfortunately, these models both suffer from shortcom¬ 
ings that detrimentally affect Alice’s communication secu¬ 
rity. The monopoly model unrealistically expects users to 
trust a single global root, such as ICANN for DNSSEC. Al- 


names 



end-entities 


Figure 1: Authentication triangle for routes, names, and 
end-entities. 


ice must assume that ICANN correctly certifies DNS records 
if she wants to have confidence in DNSSEC. As a Mythua- 
nian citizen, Alice may want to select a different set of trust 
roots from a citizen of Oceani^ but under the monopoly 
model neither citizen has a choice of trust roots. Moreover, 
the global root is a single point of failure in the monopoly 
model, which is particularly worrying in light of recent state- 
level attacks [14] [T^ [it) [2^ . 

The oligarchy model, on the other hand, gives all trust 
roots equal, global authority, allowing every trust root to 
certify information all over the world (consider the exam¬ 
ple of root certificate authorities (CAs) in TLS). However, 
this unfettered global authority lacks an isolation property: 
any compromised trust root can affect authentication for any 
entity in the world, leading to weakest-link security. Under 
this model, Alice has difficulties evaluating the trustworthi¬ 
ness of the many trust roots, preventing her from effectively 
defending herself against compromised trust roots by ceas¬ 
ing to trust them. Together with the inability to choose trust 
roots, we say that Alice lacks trust agility the ability to 
select and easily modify trust roots. Even if she can select 
trust roots in TLS, Alice may cut off access to some sites by 
deselecting certain trust roots, illustrating a need for global 
verifiability with trust agility. 

Because Alice travels frequently, she faces additional prob¬ 
lems with today’s authentication mechanisms. Due to the 

*This is the fictional state in George Orwell’s novel 1984. 
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fact that some trust roots in systems such as TLS may only 
certify information in some parts of the world, Alice may 
have to trust these roots when in the respective parts of the 
world, requiring her to constantly change her set of trust 
roots. In contrast, she should have trust mobility, the ability 
to use the same set of trust roots wherever she is in the world. 

To evaluate her confidence in a chain of signatures authenti¬ 
cating a piece of information, she should have transparent 
authentication, knowing which trust roots are involved in 
certifying the information. Finally, in order to quickly ob¬ 
tain updated trust root information in the face of a compro¬ 
mise or change, Alice should be able to learn of any changes 
to her trust roots and obtain up-to-date information quickly 
and easily, a property we call update efficiency. 

To address the above problems, we propose a Scalable 
Authentication Infrastructure for Next-generation Trust (SAINT), 
a series of architectural design changes to current authen¬ 
tication mechanisms (specifically DNSSEC, BGPSEC, and 
TLS). Using Alice’s example, we demonstrate how authenti¬ 
cation in SAINT provides stronger guarantees and additional 
properties over today’s Internet. In designing SAINT, we 
make the following contributions: 

• We propose isolation domains (ISDs), which partition 
the Internet into groups sharing common sets of trust 
roots, and scope trust root authority to these ISDs. The 
separation of ISDs allows Alice to select an ISD as a 
set of trust roots, enabling trust agility, and the scoped 
authority of each ISD’s trust roots enables isolated au¬ 
thentication. 

• We design trust root configuration (TRC) files, net¬ 
work messages containing trust root information. The 
distribution channel of these files is the same as that of 
routing messages, providing update efficiency. Addi¬ 
tionally, these files allow Alice to quickly obtain and 
use new trust root information, enabling trust agility. 

• We require cross-signing of trust roots between ISDs 
sharing a routing link using special certificates. This 
requirement enables global verifiability, so that Alice 
can verify any entity to which she has a routing path. 

The certificates used for cross-signing allow Alice to 
see the ISDs through which she is authenticating her 
destination, enabling transparent authentication. 

• We separate authentication for routing and service en¬ 
tities, preventing circular dependencies in authenticat¬ 
ing routes. This separation also enables trust agility 
and mobility, allowing Alice’s trust decisions for ser¬ 
vice entities to apply anywhere in the world. 

2. BACKGROUND 

We provide a brief overview of existing authentication in¬ 
frastructures relevant to this work and their shortcomings. 
DNSSEC was created to authenticate DNS responses 
and thus to prevent cache poisoning and other attacks against 
DNS security. ICANN operates the DNSSEC root sign¬ 
ing key, which authenticates the public keys associated with 


. com, . org, etc. In turn, these keys authenticate the next 
level of the DNS hierarchy. Clients can authenticate the 
DNS responses by starting from the root key and validating 
step-by-step the entire signature chain. 

Shortcomings. The single root of trust in DNSSEC im¬ 
plies that the entire world is required to trust the root key, 
even though the world cannot agree on a single trusted en¬ 
tity. Eurthermore, despite the measures taken to protect the 
root key from compromise, the key is still a single point of 
failure for DNSSEC. 

BGPSEC 129) and RPKI Q constitute a standard to pro¬ 
tect BGP update messages against unwarranted modifica¬ 
tions. BGPSEC relies on RPKI for prefix and router certifi¬ 
cates. RPKI enables the authentication of AS numbers and 
IP address spaces. In RPKI, each Regional Internet Reg¬ 
istry (RIR) serves as a trust anchor and signs certificates cor¬ 
responding to resources, such as autonomous system (AS) 
numbers and IP addresses, issued by that regional registry. 
Eor example, ARIN signs a delegation for an address space 
provided to AT&T, which in turn signs a delegation to a cus¬ 
tomer of its subspace. The same process occurs with AS 
numbers. Verifiers use the trust anchor managed by each 
RIR to verify the delegation chain of certificates for AS num¬ 
bers and address spaces. Before the owner of an address 
block advertises a prefix in BGPSEC, it can use the address 
block certificate to sign a Route Origin Authorization (ROA) 
to an initial AS. Each AS on the path adds a signature of its 
own and the following AS number, called a route attesta¬ 
tion in S-BGP p3| . The route attestations, together with AS 
number and address block certificates, enable validation of 
the path in BGPSEC. 

Shortcomings. RPKI’s validation process in BGPSEC suf¬ 
fers from circular dependencies. To transfer routing infor¬ 
mation, BGPSEC peers use the UPDATE message which 
contains signatures. The certificate chains for the signa¬ 
ture validation are stored at each RIR’s RPKI server. Hence, 
validation of the UPDATE message requires each BGPSEC 
router to fetch the certificates directly from the RIRs or from 
its local server, resulting in slow update propagation. 

SSL/TLS |[T5) were created to secure web connections be¬ 
tween browsers and web servers. A web site is authenticated 
through an X.509 certificate that the web site obtains from a 
Certification Authority (CA). Each browser stores the public 
root key of each trusted CA, and uses one of these root keys 
to validate a server’s certificate. 

Shortcomings. Numerous security issues exist with the 
key infrastructure since current browsers trust around 650 
root CA keys m- Additionally, CAs have global jurisdic¬ 
tion and consequently any compromised CA can issue a fake 
certificate for any server in the entire Internet. Recent attacks 
on CAs have underscored the fact that even the most widely- 
used CAs suffer from such vulnerabilities, leading to Man- 
in-the-Middle (MitM) attacks on high-profile sites | |32) . 

SCION gT) is an isolation architecture for inter-domain rout- 
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ing in the Internet. The provided isolation allows so-called 
trust domains (TDs) to distinguish between connections orig¬ 
inating from inside or outside the domain, and can guarantee 
that the path of communication between two entities in a do¬ 
main remains completely in that domain. TDs are formed 
from ASes that are naturally grouped along jurisdictional 
boundaries and who can agree on common roots of trust for 
routing information. These boundaries protect misbehavior 
in one TD from affecting routing in another TD. 

Shortcomings. SCION does not provide authentication for 
name lookups or end entities, and does not specify mech¬ 
anisms for the update or revocation of keys in the routing 
architecture. Additionally, SCION ties users to the TD in 
which they are located for all authentication, forcing them to 
trust their own TD core (which serve as routing authorities) 
for all authentication. 

Additional related work is discussed in ISection 131 

3. PROBLEM DEFINITION 

Our goal is to design global infrastructures allowing a user 
(Alice) to authenticating routes, names, and EE certificates 
(such as TLS certihcates) for a server (Bob) in the Internet. 
In a global environment such as the Internet, Alice does not 
trust all trust roots in the environment, and she and Bob may 
not even have any trust roots in common. The trust roots 
may differ in functionality and scope; some may authenti¬ 
cate routes and others names, and some may be global and 
some local. We want to minimize global authority, allow 
trust agility and mobility while maintaining global veriha- 
bility, and allow Alice to evaluate the trustworthiness of in¬ 
formation being authenticated. 

Desired properties. In order to effectively the above au¬ 
thentication problems, a network architecture should have 
the following properties: 

• Isolated authentication. The compromise of a trust 
root should be limited in scope. In particular, if Al¬ 
ice and Bob share trust roots for some information, no 
other trust root should be able to affect authentication 
of that information. 

• Trust agility. Alice should have a clear, understand¬ 
able choice over her trust roots. This choice should 
be easily modifiable at any time, with changes taking 
effect immediately (within seconds). 

• Trust mobility. Alice’s trust decisions should remain 
the same no matter where she is in the network. In 
other words, moving to different locations in the net¬ 
work should not require Alice to change her trust roots. 

• Global verifiability. As in the current Internet, Alice 
should be able to authenticate any entity in the Internet 
that can be reached and has authentication information 
such as a name or EE certificate, even if its trust deci¬ 
sion differs from hers. 

• Transparent authentication. Alice should know when 
trust roots other than her own are certifying informa¬ 
tion that she verifies. In particular, for a chain of sig¬ 


natures Alice should be able to determine which trust 
roots are responsible for each signature. 

• Update efficiency. Changes to trust root information 
(e.g., new keys and revocations) should take effect quickly 
(within minutes). In particular, Alice should be able to 
detect and obtain new information without requiring 
software updates. 

Adversary model. Our adversary is an individual or organi¬ 
zation whose goal is to convince Alice of false information 
for a route, name, or EE certificate. To achieve this goal, 
the adversary can actively suppress, change, replay, or inject 
messages into client-server communication, and might also 
gain access to the private keys of trust roots in one domain. 
However, besides these capabilities, the adversary cannot 
break cryptographic primitives such as public-key encryp¬ 
tion and hash functions. 

Other assumptions. In order for Alice to successfully ver¬ 
ify authentication information, she must also be able to ver¬ 
ify a set of trusted public keys which can then be used to 
bootstrap trust in other keys used during authentication. We 
therefore assume that users like Alice can verify an initial set 
of public keys through an out-of-band mechanism. 


4. SAINT OVERVIEW 

In this section, we highlight important features of SAINT. 
We provide intuitive explanations of how these features ac¬ 


complish the desired properties mentioned in Section 3 and 
how they fit into the overall SAINT architecture. 

4.1 Isolation Domains (ISDs) 

The Internet consists of a diverse assortment of groups, or 
domains, each with its own set of trusted parties and individ¬ 
ual policies regarding routing, naming and EE certification. 
We make these differences a central part of the SAINT archi¬ 
tecture in order to achieve isolated authentication. SAINT 
groups hosts, routers, and networks into isolation domains 
(ISDs), such as those shown in [Eigure^ S AINT’s ISDs 
are inspired by SCION’s trust domains m and leverage 
SCION’s routing infrastructure. However, SAINT’s ISDs 
provide additional authentication mechanisms for naming 
and EE certification. 

An ISD is a collection of ASes with a common set of trust 
roots (see Eigure 4| i. These trust roots manage authentication 
within their ISD, including management of routing, naming, 
and EE certification policies, but are not authorities outside 
of the ISDs. The structure of ISDs attempts to model ex¬ 
isting trust relationships between humans by grouping those 
with similar trust decisions together and by protecting users 
from misconfigurations or breaches of trust outside these 
“circles of trust’’ where other trust decisions and policies 
hold. Thanks to ISDs, Alice can select her roots of trust 
and when communicating within her own ISD, she can stay 
protected from compromised trust roots outside of her ISD. 
[Section Sl describes the structure of ISDs in more detail. 
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Figure 2: Two isolation domains with individual trust 
roots. The trust roots are illustrated in [Figure 4[ The 
solid lines indicate provider-to-customer relations; the 
dashed lines indicate peering links. 


In practice, ISDs can represent groups of various scales, 
such as companies, conglomerates, or countries. ISD-level 
policies will vary greatly by the scale of the ISD, since cor¬ 
porate policies often contain much more detail than country¬ 
wide laws. In this paper we use countries as examples of 
ISDs for several reasons: (1) international boundaries ap¬ 
proximately map to DNS naming boundaries, which are also 
separated in SAINT, (2) national data privacy laws provide 
a reasonable example of security policies in top-level ISDs, 
and (3) the resulting set of domains represents an easily- 
understood choice among possible sets of trust roots, since 
users can more easily understand what it means to evaluate 
and trust a country (representing a set of trust roots) rather 
than doing so with individual trust roots. 


4.2 Trust Root Configuration (TRC) Files 

Trust root management in SAINT is handled by TRC files, 
which contain information about an ISD’s trust roots, such 
as their public keys (see Section 6.2 for more details). TRC 
files are disseminated as network messages along the same 


channels as routing messages and DNS responses (see Sec- 


tion 6.3|), providing update efficiency. Because routing mes¬ 


sages are required to maintain connectivity, new TRC files 
can quickly propagate throughout the network in case a trust 
root is compromised. This mechanism allows Alice to quickly 
obtain up-to-date trust root information. 

In addition to the above distribution mechanisms, TRC 
files can also be downloaded and chosen by the users as a 
new set of trust roots. Since a TRC file contains all of the 
necessary trust root information, a user like Alice can easily 
switch to a different set of trust roots by simply obtaining 
and selecting a different TRC file. In essence, SAINT pro¬ 
vides trust agility by allowing users to easily modify their 
trust decisions at any time. 

TRC files contain trust root information for a given ISD 
and thereby enable transparent authentication. Namely, when 
a trust root signs the information of another ISD’s trust root 
(as explained below), it does so by signing the TRC file of 
the other ISD. Thus a chain of signatures clearly indicates 
domain boundaries by design. Alice can use this knowledge 
of ISD boundaries to evaluate the trustworthiness of this sig¬ 


nature chain and determine whether or not to accept the au¬ 
thenticated information. 

4.3 Cross-Signing Trust Roots 

If we consider ISDs as countries, then we can clearly see 
that not all ISDs’ trust roots will cross-certify one another, 
and it is unrealistic to expect countries to do so. Rather, we 
only require the trust roots of two ISDs to cross-certify one 
another if they share routing links, that is, if they are phys¬ 
ically connected and route traffic through one another. This 
requirement ensures that the existence of a routing path im¬ 
plies the existence of a chain of signatures for a name or EE 
certificate, providing global verifiability by allowing Alice 
to verify this information for any entity she can reach (see 
[Section Tj for more details). 

This cross-signing requirement also helps to provide mo¬ 
bility: no matter where users are located, they can authenti¬ 
cate service information (names and EE certificates) starting 
from their own trust roots (named in their “home” TRC file) 
to the ISD of the entity whose information they are verify¬ 
ing. Thus as long as Alice can reach her home ISD from the 
ISD in which she is located, she can use her existing trust 
decision for authentication anywhere in the world. 

4.4 Separation of Authentication Types 

SAINT separates routing authentication from service authen¬ 
tication (which certifies names and EE certificates). Because 
authentic routes are required to fetch necessary information 
during name lookups and EE certificate handshakes, we treat 
routing as a separate authentication mechanism. Moreover, 
we note that authentication of routes cannot rely on fetching 
external information, as this would itself require authentic 
routes and thus create a circular dependency. 

The separation of routing and service authentication also 
helps provide trust mobility in SAINT. We observe that users’ 
physical locations indeed influence their routing authentica¬ 
tion; in particular, a route from Alice to Bob must be authen¬ 
ticated by trust roots of the ISDs in which Alice and Bob are 
located. However, this requirement does not hold for service 
authentication; thus Alice can use the trust roots of an ISD 
of her choosing to completely bypass the ISD in which she 
is located to authenticate names or EE certificates, providing 
trust mobility and greater resilience against MitM attacks. 


5. ISOLATION DOMAINS 

We now discuss isolation domains in more detail. We be¬ 
gin by describing the physical layout of ISDs along with the 
structure of the namespace and the address space in SAINT. 
We then present the concept of trust anchor ISDs, which pro¬ 
vide starting points for the authentication of routes, names, 
and EE certificates. 


5.1 ISD Structure 

An ISDs is made up of multiple networks, or ASes, as shown 


Eigure 2 with ISDs connecting to one another to en- 
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Figure 3: Namespace structure in SAINT. Solid lines in¬ 
dicate hierarchical relations, and dashed lines indicate 
redirections. 


able Internet-wide connectivity. Similarly to trust domains 
in SCION, SAINT arranges ASes hierarchically within an 
ISD by customer-provider relationships. The ASes in the 
top tier (those with no providers) are referred to as the ISD 


core and serve as the trust roots for routing (see Figure 4 and 
[Section 6T| for more details). 

The connectivity of ASes in SAINT is similar to the cur¬ 
rent BGP-based relations: ISDs are primarily connected by 
links between ISD core ASes (similar to BGP transit links 
between tier-1 ISPs), but can also be connected by links be¬ 
tween lower-tier ASes (similar to BGP provider-customer 
links and peering links). Paths between ISD cores are de¬ 
termined by a simple routing protocol among the core ASes 
of each ISD. Based on our analysis of the current Internet 


(Section 111, we expect that there will be on the order of 
several hundred core ASes in total. Therefore, in running 
such a protocol we do not worry about significant overhead 
or scalability. 

5.2 DNS Namespace 

Each ISD has the autonomy to manage its own namespace. 
We structure SAINT’s global namespace as a collection of 
top-level domains (TLDs) bound by an inter-domain web of 
trust (as shown in Figure 3| l, rather than by a global 
root zone as is done in DNSSEC. However, SAINT’s name 
resolution process is similar to that of DNSSEC. 

Each SAINT DNS root server answers queries for hosts 
within its ISD. An ISD’s namespace supports one of two 
top-level domain types: 

• Regional TLDs in SAINT correspond to a specific ISD. 
In the example of Figure 3| the TLD . us represents the 
United States ISD, whereas . uk represents the United 
Kingdom ISD. In order to provide transparency, the 
DNS server responsible for a regional TLD guarantees 
that any address record (similar to A records in DNS) 
maps to an address within the corresponding ISD. 

• Generic TLDs such as . com and . org, by contrast, 
are not bound to any specific ISD, and can thus name 
an entity located anywhere in the world. However, a 
name in a generic TLD can only map a redirection to 
another name, thereby ensuring that only names under 


regional TLDs map to addresses (and only within the 
TLD’s corresponding ISD). This guarantee provides 
domain transparency during DNS lookups. Details about 
name resolution for generic TLDs are in Appendix [TS] 

We expect that today’s ccTLDs such as .us and .uk will 
continue to operate as regional TLDs under SAINT. Coun¬ 
tries such as Tuvalu (whose ccTLD is the popular . tv) may 
choose to operate as a generic TLD and continue to sell 
names that map all over the world, but must do so through 
redirections to other names. 

5.3 Address Space 

We define an address in SAINT as a 3-tuple of the form 
(I,A,e), where X represents an ISD identifier, A represents 
an AS identifier (ASID), and e represents an endpoint identi¬ 
fier LID. For example, if Alice wants to reach Bob, who has 
the LID 42ac6d in AS 567 and ISD X, she would contact the 
address (I,567,42ac6d). In contrast to the current Internet, 
AS numbers and EIDs do not have significance outside of 
their respective ISDs and ASes, and thus can have any for¬ 
mat. An LID, for example, can be an IPv4, IPv6, MAC, or 
self-certifying address. 

Registry servers in ISDs (described in [Section CT) as¬ 
sign ASIDs to ASes, and similar servers in each AS issue 
EIDs to endhosts. Due to the local significance of ASIDs 
and EIDs, {X,A,e) and {J,A,e) are distinct addresses even 
though both have the same ASID and LID. This addressing 
scheme allows full address to be globally unique while giv¬ 
ing ISDs and ASes the autonomy to manage addressing as 
well as names within their own realm of control. 

The above addressing system also allows for interoper¬ 
ability with the current IP addressing and AS numbering 
schemes while simultaneously enabling local deployments 
of other proposed addressing schemes. For example, some 
ISDs may choose to retain the current AS numbering and IP 
addressing schemes, while others may opt to provide ASes 
with human-readable identifiers and endpoints with IPv6 ad¬ 
dresses. 

Similarly to ASIDs, endpoint addresses (since only used 
locally in intra-AS routing) do not need to be globally al¬ 
located like the current IP address space. Since the routing 
authentication infrastructure only handles inter-AS routes, 
SAINT does not bind the endhost address space to public 
keys as RPKI does. Instead, forwarding from an edge router 
to an endpoint address is resolved and handled entirely within 
an AS. 

5.4 Trust Anchor ISDs 

Trust anchors in the current Internet, such as lANA for RPKI 
and BGPSEC, ICANN for DNSSEC, and root CAs in TLS, 
represent starting points for authenticating information. Sim¬ 
ilarly, trust anchor ISDs are starting points for authenticating 
routes, names, and EE certification in SAINT. Due to the 
separation of authentication by type, Alice can anchor her 
trust for authenticating routing and service information in 


5 














































Figure 4: Logical and physical placements of trust 
rootsin an ISD. 


separate ISDs. 

As discussed in Section 4.4 for routing purposes the trust 
roots of the ISO’s in which Alice is currently located must 
certify all of her routes. However, Alice can select the trust 
roots of any ISD to authenticate service information (names 
and EE certihcates). We call this ISD Alice’s trust anchor 
ISD. Alice choice of this ISD can be easily changed at any 
time (as described in Section 63]l. An example of such trust 


bootstrapping is provided in Section 9 


6. TRUST ROOTS 

In this section, we cover what entities serve as trust roots and 
how trust roots are conhgured for an ISD. We also discuss 
how we update trust root information using network-level 
messages, and how this incorporation of trust management 
into the network allows for fast updates of trust root infor¬ 
mation. Einally, we describe our scheme of separating trust 
roots by ISD, and how separated categories of authentication 
enable trust agility. 

6.1 Trusted Parties 


Trust roots sign authentication information for routes, names, 
or EE certihcates, and set policies governing the ISD. These 
policies may include information such as preferences for cer¬ 
tain encryption or signature algorithms or constraints on cer- 
tihcate validity. A trust root is an authority for either routing 
or service authentication (see Eigure A\ . 

Because a trust root is only an authority in its own ISD, a 
compromised trust root cannot enable the impersonation of 
servers in other ISDs. Scoping trust root authority to the ISD 
level protects Alice and Bob’s communication from many 
compromises in other ISDs and provides guarantees to Alice 
about authentication in her trust root ISD. 

We classify trust roots into routing and service trust roots. 
The routing trust roots consist of the following parties: 

• The core ISPs are responsible for sending out route an¬ 
nouncements, which are propagated from providers to 
customers and establish cryptographically signed paths 
from the recipient to the core. 

• The path server stores and provides a lookup service 
for mappings between an ASID and the AS’s down- 


paths. These paths are registered by the ASes at the 
core. The path server is co-located with and operated 
by the core ISPs. 

• The registry server issues and stores AS certificates 
binding an ASID to its public key (called its AS key), 
which are used to verify the signed paths provided by 
the path server. Like the path server, the registry server 
is co-located with and operated by the core ISPs. 

The service trust roots consist of the trust roots for nam¬ 
ing and for EE certihcation. The DNS root is the starting 
point for verifying all names in the ISD’s namespace. The 
DNS root also sets ISD-wide naming policies such as re¬ 
served or forbidden domain names and allowed signature al¬ 
gorithms to sign records. Because the failure of the DNS 
root can block user connectivity in an ISD, the DNS root 
should be highly robust and available, using mechanisms 
such as distributed anycast schemes and placing servers in 
the ISD core where they can be reached through highly avail¬ 
able top-tier ASes. 

The root CAs are the starting points for verifying EE cer¬ 
tihcation information in an ISD. Root CAs in SAINT serve 
the same purpose as they do in today’s PKIs by signing TLS 
public-key certihcates. However, they are restricted to only 
signing EE certihcates in ISDs in which they are root CAs. 
They can also sign intermediate CA certihcates as in to¬ 
day’s TLS PKI. If the ISD uses other public-key infrastruc¬ 
tures such as CT or AKI (see [Section 12) 1, then the trust 
roots for EE certihcation also include public logs and au¬ 
ditors/validators. 


6.2 Trust Root Configuration (TRC) Files 

As mentioned in Section 4~2l a TRC hie specihes the trust 
roots for an ISD, the public keys of those trust roots, and 
the authentication policies of the ISD. It also specihes the 
locations of the DNS root and TRC servers (described in 
Section 63]l to allow users to reach these servers without per¬ 


forming DNS lookups. TRCs are created and managed by an 
ISD’s trust roots and distributed through the routing mech¬ 
anism. Specihcally, a threshold of trust roots is required to 
sign a new or updated TRC hie, and the core ISPs distribute 
the TRC hie within the ISD through a broadcast mechanism 
that we describe below. 

The quorum of trust roots required to update the TRC hie 
is specihed in the TRC hie itself, providing the trust roots 
with the autonomy to set their own threshold for altering the 
TRC hie. A higher threshold is more secure to a compro¬ 
mise of multiple trust roots, but also reduces the efficiency 
in updating TRC hies. The TRC hie also specihes a quo¬ 
rum of trust roots that must sign a cross-signing certihcate 
to authenticate another ISD’s trust roots. Cross-signing cer¬ 
tihcates are described in more detail in lSectionTl 


TRC format. A TRC hie is encoded as an XML hie with the 
helds shown in |Eigure31 The version number and timestamp 
ensure that users can verify information using recent policies 
and trust root information. The public keys of the ISD’s trust 
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Field 

Description 

isd 

ISD identifier 

version 

Version of TRC file 

time 

Timestamp 

corelSPs 

List of core ISPs and their public keys 

registryKey 

Root registry server’s public key 

pathKey 

Path server’s public key 

rootCAs 

List of root CAs and their public keys 

rootDNSkey 

DNS root’s public key 

rootDNSaddr 

DNS root’s address 

trcServer 

TRC server’s address 

quorum 

Number of trust roots that must sign new TRC 

trcQuorum 

Number of trust roots that must sign an ISD cross-signing cert 

policies 

Additional management policies for the ISD 

signatures 

Signatures by a quorum of trust roots 


Figure 5; Fields in a TRC file. 




Figure 6: Distribution mechanism for updated TRCs. 
Arrows indicate sent network messages. 


roots provide starting points for verifying routes, names, and 
EE certificates. The TRC file may also contain the public 
keys of additional entities (e.g., public logs in CT or 
AKI p4|). In order to allow users to easily reach the DNS 
root of an ISD, the TRC also contains one or more addresses 
for the ISO’s DNS root. 


obtain a different ISO’s TRC file, she can contact the TRC 
server of that ISD, a server that stores the TRC files and 
cross-signing certificates (see Section 7 1 of other ISDs. The 
TRC server’s address is in the TRC file of the ISD, allowing 
Alice to directly query the server for other TRC files. In an 
extreme case where Alice does not trust the provider or ISD, 
she may download a TRC file from a publicly-accessible 
mirror site or obtain one in person from a trusted colleague 
or organization. Alice can also obtain a TRC file a priori if 
she plans to join such an ISD with a new device. 


Obtaining updated TRC files. ASes and users in an ISD 
are informed of the latest version of the TRC file with each 
routing announcement and DNS response. Thus, as long as 
Alice has an Internet connection and performs DNS lookups, 
she can quickly detect and obtain a new TRC. The version 
number is part of each routing announcement, and a times- 
tamped message signed by the trust roots accompanies each 
DNS answer (to avoid re-signing every DNS record in the 
ISD upon updating the TRC file). When Alice detects a new 
TRC file, she can fetch the new file from the provider or 
DNS root (see|Eigure 6|l. 


Changing trust anchor ISDs. Besides the ability to select 
trust roots as described in Section 5.4 trust agility also pro¬ 
vides the ability to easily and quickly modify this selection. 
The above methods of obtaining TRC files provide this no¬ 
tion of trust agility, as Alice can change trust anchor ISDs 
by simply obtaining a new TRC file. Under normal circum¬ 
stances Alice can simply download a new TRC file from her 
trust anchor ISD’s TRC server, but if for example she discov¬ 
ers that her trust anchor ISD has been conducting state-level 
surveillance, she can instead obtain the TRC file manually 
or from an external server as described above. 


Policies. A TRC file can also specify additional policies re¬ 
lated to ISD management. Eor example, these policies might 
specify a minimum key length or required encryption algo¬ 
rithms for all EE certificates in the ISD. Systems such as Po- 
liCert have proposed similar policies on a per-domain 
basis; we leave a detailed design of additional ISD-wide 
policies to future work. 

Updating the TRC file. In the event that a TRC file needs 
to be updated, the trust roots confer out of band to determine 
what changes need to be made to the TRC file. Once they 
have decided to update a TRC file, the trust roots sign the 
new TRC file. Each of these signatures is appended to the 
signatures section of the new TRC file, and sent when a 
quorum of tmst roots signs the TRC file. The trust roots can 
also use group signatures GD or threshold signatures to 
update the TRC file. 

6.3 TRC Distribution and Management 

Obtaining an initial TRC file. We envision that Alice will 
most commonly obtain a initial TRC file of her provider’s 
ISD when forming a service agreement. If Alice wants to 


7. CROSS-SIGNING 

In this section, we provide a detailed discussion of cross¬ 
signing in SAINT. We begin by describing cross-signing cer¬ 
tificates, and then detail how these are used to enable inter- 
ISD authentication and global verifiability. We then discuss 
the tradeoff between global verifiability and the trustworthi¬ 
ness of authenticated information, and how the authentica¬ 
tion policies expressed in an ISD’s TRC file fits in this trade¬ 
off. 

7.1 Cross-Signing Certificates 

In order to enable global verifiability, we require ISDs to is¬ 
sue cross-signing certificates for its neighboring ISDs, that 
is, ISDs with which they share routing links. The resulting 
web of cross-signing between ISDs ensures that by follow¬ 
ing a route from Alice’s ISD to Bob’s ISD, a corresponding 
chain of signatures from Alice’s trust roots to Bob’s tmst 
roots will exist, forming a chain of signatures from Alice’s 
trust roots to Bob. ISDs without direct routing connections 
can also issue cross-signing certificates to one another, form¬ 
ing further chains of signatures to enable authentication be- 
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tween different ISDs directly. 

A cross-signing certificate issued by X for J\ trust roots 
contains (a) a timestamp, (b) I, (c) the current version num¬ 
ber of 7i, (d) J, (e) the current version number of 7j, (f) a 
hash of and (g) a signature by a quorum of I’s trust roots 
(see Figure 7 for an explanation of notation). The version 
numbers of the TRC files ensure that the trust roots’ public 
keys can be checked against the appropriate versions of the 
TRC files. 

The ISD stores these certificates in its TRC server for its 
users and also propagates the certificates along its inter-ISD 
routing links to provide each ISD with the necessary infor¬ 
mation to form a chain of signatures to a given destination 
ISD. Alice can then query her trust anchor ISD to obtain 
these chains of signatures and select one to authenticate in¬ 
formation in Bob’s ISD. 


7.2 Inter-ISD Authentication 

When Alice, whose trust anchor ISD is /C, wants to authen¬ 
ticates Bob, who is in another ISD M., she needs to obtain 
cross-signing certificates to form a chain of signatures from 
/C to M.. While verifying Bob’s routes, name, and EE cer¬ 
tificate, she obtains the appropriate cross-signing certificates 
from /C’s TRC server. If Alice is in an ISD I, then every 
route from her to Bob will have a chain of signatures start¬ 
ing at /C, proceeding to the trust roots of I, then to the trust 
roots of M., and finally to Bob’s AS. 

If K, and XA do not share routing links but have issued 
cross-signing certificates to each other, Alice can verify Bob’s 
name and EE certificate using /C’s cross-signing certificate 
for Af. These cross-signing “shortcuts” allow Alice to au¬ 
thenticate Bob’s information with fewer ISDs authenticating 
information “in transit,” providing fewer opportunities for a 
compromised trust root to disrupt authentication. 

No matter where M. is, Alice is guaranteed to find a chain 
of signatures to Af and to Bob if she can find a route to Bob. 
Since she must be able to contact K, from X to obtain the ap¬ 
propriate cross-signing certificates, she has a route between 
Yi and X and can thus obtain cross-signing certificates from 
/C to X, and similarly for X and Af. Though a chain of sig¬ 
natures may cross many ISDs, Alice is guaranteed to find at 
least one such chain. 

Note that cross-signing certificates do not necessarily in¬ 
dicate a trust relationship between ISDs; a cross-signing cer¬ 
tificate instead only states: “These are the public keys of the 
trust roots for the following ISD.” It is therefore up to Al¬ 
ice to determine the trustworthiness of a chain of signatures 
before accepting the information it certifies as authentic. 

7.3 Authentication Policies 

The above cross-signing requirement ensures that Alice can 
authenticate Bob’s information regardless of which ISD he 
is in. While a compromised trust root on a chain of signa¬ 
tures from Alice to Bob can adversely affect authentication 
by certifying false information, Alice’s trust anchor ISD /C 


can mitigate this risk through the use of ISD-wide policies 
in the TRC file. These policies can also blacklist public 
keys, such as those contained in known unauthorized cer¬ 
tificates or those of compromised trusted authorities. Us¬ 
ing such policies, K can protect Alice from compromises in 
other ISDs. If others with /C as their trust anchor ISD fre¬ 
quently contact Bob or other destinations in Al, then K may 
form a cross-signing relationship with Al to minimize the 
risk of compromised trust roots in other ISDs. 

ISDs face a tradeoff between enabling global verifiability 
and protecting their users from compromises in other do¬ 
mains. The default behavior in SAINT is to provide global 
verifiability. As illustrated above, an ISD must explicitly 
state any exceptions to this behavior in the policy field of its 
TRC file. The ability to restrict the authentication of known 
false information through policies provides a mechanism by 
which an ISD can protect not only its own users, but also 
users for whom a chain of signatures passes through the ISD. 

8. SEPARATED AUTHENTICATION 

In this section, we describe how SAINT separates routing 
and service authentication. We first describe our motivation 
for separating these two types of authentication, and then 
discuss how this separation provides Alice with trust mobil¬ 
ity. 


8.1 Routing and Service Authentication 

Authentication in SAINT is classified and separated into rout¬ 
ing and service authentication (see Eigure l| l. We make this 
separation in part because we observe that the authentication 
of route information fundamentally differs from the authen¬ 
tication of service information. In particular, routing authen¬ 
tication cannot assume the existence of secure routes to ob¬ 
tain any external information, and therefore an entity must 
rely on pre-verified paths or be able to verify paths without 
fetching external information. By contrast, service authen¬ 
tication assumes the existence of authentic routes and thus 
allows contacting external entities to obtain authentication 
information. 

Routing messages in SAINT propagate beginning from 
the ISD core and follow provider-customer AS links. Un¬ 
like in RPKI and BGPSEC, all necessary information (e.g. 
AS certificates) are sent with the routing message, allowing 
an AS to verify routing messages upon arrival. Moreover, in¬ 
formation such as AS certificates are short-lived, eliminating 
the need to propagate revocation information for AS keys. 

By contrast, a DNS lookup, which falls under service au¬ 
thentication, must use a route to reach one or more name- 
servers and fetch the appropriate information for verifying a 
name-to-address mapping. TLS features such as OCSP also 
require contacting an external entity to determine the valid¬ 
ity of an EE certificate. Due to this dependence, Alice must 
verify routes to the ISD core of her current ISD X, and form 
and verify routing paths from X to Bob’s ISD Al before she 
can authenticate Bob’s service information. 
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Notation 

Name 

Use 

Identifiers 

X 

AS 

AS with ASID X 

y 

Endhost 

an end-entity such as a client or server 

By 

EID 

locate endhost y within its AS and ISD 

z 

ISD 

ISD with identifier Z 

Certificates 

ACx 

AS cert 

bind X to AKx (signed by RS of X’s ISD) 

ECy 

End-entity cert 

store CA-signed public key information during 



connection setup 

DCy 

CERT RR 

store CA-signed DNS binding between y and DKy 

Keys 

AKx 

AS key 

sign paths that can be used to reach X 

DKy 

DNSKEY RR 

sign DNS resource records in DNSSEC 

EKy 

End-entity key 

set up secure end-to-end connections, e.g., via TLS 

K~' 

Private key 

private key for public key Ky 

Servers 

PSy 

AS Path server 

contact ISD path server for clients in Y 

PSz 

ISD Path server 

maintain database of signed paths for ASes in Z 

RSz 

Registry server 

assign ASIDs and AS numbers in Z 

Messages 

Px 

Signed path set 

sent to PS of X’s ISD to register paths to reach X 

Tz 

TRC file 

provide trust root information for Z 


Figure 7: Notation. 


8.2 Trust Mobility 

Separating routing and service authentication also enables 
trust mobility. Suppose that Alice checks into a hotel in 
Oceania, a known surveillance state, and attempts to connect 
to her hotel’s wireless Internet. If the Oceanian trust roots 
are compromised by the government, then it is inevitable that 
the government can see her packets themselves, as her phys¬ 
ical location in Oceania enables the government to examine 
her packets. In other words, Oceanian trust roots must cer¬ 
tify her routes out of the Oceanian ISD and thus these trust 
roots must be on the chain of signatures for routes from Al¬ 
ice to any destination in the Internet. 

With SAINT, however, Alice can choose JC as her trust an¬ 
chor ISD for service authentication, since SAINT separates 
routing and service authentication. Moreover, this choice 
does not depend on Alice’s current location and thus applies 
wherever Alice is in the Internet. In our example, this means 
that Alice does not have to rely on signatures from the Ocea¬ 
nian trust roots to verify Bob’s name or EE certificate, even 
if she is connecting to the Internet from an Oceanian hotel. 


9. AUTHENTICATION EXAMPLE 


We now discuss the complete authentication process in SAINT. 
We first describe setup steps for a server, such as joining an 
ISD and registering domain names, routing paths, and EE 
certificates. We then describe how Alice (the client) checks 
the information that she receives about Bob (the server). We 
use a to denote Alice and b to denote Bob. As previously 
mentioned, Alice’s trust anchor ISD is 1C. Bob is part of 
the AS B in Mythuania Ai, whose ccTLD is .my. Eigure 7| 
provides a list of the notation used. 


9.1 AS Setup 

[Figure 8| depicts the steps of the AS setup process for AS B 
in the Mythuanian ISD AA: 

1. RSm assigns the ASID B to Bob’s AS. 



Figure 8: Diagram for AS setup steps ( [Section 9TI) . 



2. B creates an AS key pair {AKb,AK^^). 

3. B sends {B,AKb} to RSm- 

4. RSm issues B an AS certificate ACb- 

5. B receives the TRC file Tm from its parent AS. 

6. B receives SCION routing messages from its parent. 

7. B selects a set of paths Pb (signed with AK^^) and 
sends {Pb,ACb} to PSm- 

9.2 Server Setup 

shows the steps of the server setup process for Bob; 

B assigns Bob the EID et, making his address {Ai,B,eh). 

2. Bob chooses the name b.my and creates a domain- 
name key pair {DKt,,DK^^). 

3. Bob sends b. my and DKj, to the . my operator to regis¬ 
ter his name and key|^ 

4. The . my operator creates a delegation signer (DS) record 
to point to DKb from the . my zone, as well as a record 
mapping b .my to Bob’s nameserver. 

5. Bob creates a mapping of www.b.my to {Ai,B,ei,), 

DKh, and resource record signature (RRSIG) record of 
the mapping signed with DK^ ^. 

6. Bob creates an end-entity key pair (EKb^EK^^). 

7. Bob sends {b,EKi,} to a CA in A4. 

8. The CA issues Bob an EE certificate = {b,EKi,}„-i. 

9. Bob creates a certificate DCt = {b.my,DKi,}„„-i, and 

stores DCb along with ECb as a CERT record in his 
nameserver. 

9.3 Client Setup 

^In practice, Bob will create multiple key pairs and use one of the 
private keys to sign the others, but for simplicity we assume here 
that Bob uses DKb both to sign his DNS zone information and to 
self-sign DKb- 


Figure 9 
1. AS 
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Figure 10: 
|tion 9.3) . 


Diagram for obtaining a TRC file (Sec- 



Figure 11: Client lookup and verification of server’s 
name, route, and EE certificate ( [Section 9 ^ . 


In order for Alice to verify information, she must first pos¬ 
sess a TRC file to configure her set of trust roots. Even if 
she does not have a TRC hie, we assume that she can verify 
a TRC hie from her trust anchor ISD K,. In fact, she can ver¬ 
ify this TRC hie in any ISD I — even if she does not trust I. 
As illustrated in |FigureT0| after connecting to the Internet in 
I, Alice does the following to obtain and verify a TRC hie; 

1. Alice’s ISP (AS C) assigns her the EID making her 
address (I,C,ea). C also sends her the latest TRC hie 
Tx for the ISD I. 

2. Alice requests from PSc a path to the TRC server TSx 
of I or TSic of K, (if she knows the address). 

3. PSc returns to Alice the path she requested. 

4. Alice now contacts either TSi (4a in |FigureT0 1 or TSic 
(4b) and requests Tjc- In the case of 4b, Alice also 
requests a cross-signing certihcate for X from TSjc to 
ensure that all authentication (even for routes) begins 
from T]c- 

5. If Alice contacted TSi, she receives Tiq (5a). Other¬ 
wise, she receives 7)c the cross-signing certihcate 
fori from TSk. (5b). 

We assume that Alice verihes the authenticity of Tjq through 
an out-of-band mechanism, e.g., if she makes plans to travel 
to I and considers it a “hostile” ISD, then Alice can obtain a 
hash of the public keys of /C’s trust roots a priori, or she can 
obtain this information in an embassy of K, within I. 


9.4 Client Verification 


Figure 11 illustrates the complete process that Alice executes 
to authenticate Bob. We assume that Alice has completed 


the client setup process and thus has Tx: to use as the starting 
point for authenticating Bob. The authentication process is 
as follows: 

1. Alice begins by looking up www. b. my, and thus first 
obtains Tm- She contacts PSc to obtain a path to TSx:- 

2. PSc returns to Alice a set of paths that she can use to 
reach TSx:- 

3. Alice contacts TSx: to request Tm- 

4. TSx: returns Tm and a cross-signing certihcate for XA- 

5. Alice contacts PSc to request a path to the DNS root 
of XA, whose address she has from Tm- 

6. PSc returns to Alice a set of paths to Al’s DNS root. 

7. Alice contacts Ad’s DNS root to query www. b. my. 

8. Alice performs DNSSEC resolution to obtain {Ai,B,eh) 
as well as Bob’s domain and EE certs DCb and ECb- 

9- Alice requests a path to Bob’s address from PSc- 

10. PSc returns to Alice B’s AS certihcate ACb and a set 
of paths Pb to reach B- 

11. Alice contacts Bob to initiate the TLS handshake. 

12. Bob sends Alice his EE certihcate ECb- 

Alice verihes that Bob’s EE public key EKb contained in 
the EE certihcate she obtained from Al’s DNS root matches 
the EE public key she receives during the TLS handshake. 

If the keys match, she proceeds with the TLS handshake to 
establish a secure end-to-end connection with Bob. 

Throughout this process, Alice verihes that valid authen¬ 
tication paths exist for each entity she contacts; PSc, TSx:, 
Ad’s DNS root, B, and Bob. When she receives information 
signed by the trust roots of an ISD other than 1C, Alice uses 
the appropriate cross-signing certihcate to verify the public 
keys of the ISD’s trust roots, thus ensuring that all authenti¬ 
cation ultimately begins with trust roots listed in the TRC of 
her trust anchor ISD K,- 

Error handling. A verihcation failure at any stage in the 
authentication process will prevent Alice from authenticat¬ 
ing and establishing a connection to Bob. In the event that 
the verihcation of a routing path fails, Alice will not be able 
to reach Bob or entities such as DNS roots and TRC servers. 
However, Alice likely cannot detect this failure from her 
browser. In the event that the verihcation of Bob’s name- 
to-address mapping fails, Alice will not know the address at 
which she can reach Bob. While most modern browsers in¬ 
dicate such a failure, Alice cannot proceed with verihcation 
after such a failure. From the perspective of Alice’s browser, 
a failure to verify Bob’s EE certihcate is the most informa¬ 
tive, as most modem browsers display the type of error that 
occurred and in some cases provide the option to continue 
with the connection anyway. 

10. IMPLEMENTATION AND EVALUATION 

In this section, we describe our prototype implementation 
of SAINT. We used this implementation to evaluate the per¬ 
formance of authentication and trust root management func¬ 
tions; we also discuss our evaluation results here. 
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SAINT Daemon 



Measurement 

Min 

Max 

Med 

Avg 

DNS resolution 

199 

967 

557 

500 

Path verification 

348 

1691 

691 

652 

Certificate validation (TLS) 

210 

1 123 

222 

233 

Certificate validation (TLS+CRL) 

401 

1775 

440 

460 


Kernel 

space 


H NetFllter Queue 


Figure 14: Evaluation results (in microseconds). 


Figure 12: Architecture for endhost implementation. 



Figure 13: CDF of the percentage of vantage point ASes 
using a new TRC after propagation from the core ISPs. 


10.1 Implementation 

We implemented the endhost side of SAINT (see Figure 12 1 . 
The main component of our implementation is the SAINT 
daemon, which acts as a gateway between applications and 
the network. The SAINT daemon includes SCION layer 
support for packet encapsulation and decapsulation, a path 
engine for route management and verification, a name lookup 
engine for SAINT name queries, and a TRC engine, which 
allows users to obtain and verify TRC files. 

Traffic generated by the applications is delivered to the 
SAINT daemon by the NetFilter queue, allowing legacy ap¬ 
plications to deploy SAINT without requiring any changes. 
We ran our simulation on an Intel Core i5-3380M CPU at 
2.90 GHz, 16 GB of RAM, Python 3.4, and gcc 4.8.2. We 
used ed25519 Q as our signature scheme for name and path 
verification, and RSA-2048 for TLS certificates. 


10.2 TRC Updates 

We measured the efficiency of TRC distribution and updates 
by simulating the propagation through the current AS topol¬ 
ogy. We used the CAIDA inferred AS relationships dataset 
from October 2014 0 as our model of the current topol¬ 
ogy, and used traceroutes from iPlane dataset^ to estimate 
inter-AS latency. From each of iPlane’s vantage point ASes 
(distributed throughout the world), we identified the latency 
(half of the RTT) to each of the top-tier Ases identified using 
the CAIDA-based topology. 

Our evaluation demonstrates that more than half of our 
vantage point ASes receive a new TRC file within 100 ms 


of the file being sent from the core ISPs (see Figure 131. 
Moreover, all vantage point ASes receive the new TRC file 
within 600 ms. Our vantage point ASes included stub ASes 


^http://iplane.cs.washington.edu/data/data.html 


(that is, ASes with no customer ASes), demonstrating that 
end users around the world can quickly receive updated TRC 
files. These results show that our TRC propagation mecha¬ 
nism is significantly more efficient than the current trust root 
update mechanisms in browsers (which typically occur on 
the order of days). 


10.3 Authentication Overhead and Performance 


To test the actual latency of authentication in SAINT, we 
measured 300 end-to-end secure connection establishments 
on a sample SCION topology of virtual machines. Figure 14l 
shows the timing results, which only reflect the cryptographic 
verifications and do not take into account network delay, 
since a full network deployment of SCION is not available 
at this time. However, our results give us an insight into the 
overhead of SAINT. In particular, all functions take less than 
1 ms on average, which is significantly less than the end-to- 
end round trip time in an actual connection establishment. 

As a baseline, we measured end-to-end connection estab¬ 
lishments to 100 HTTPS sites on the current Internet ran¬ 
domly selected from httpsnow. org. We observed 418 sep¬ 
arate TLS connection establishments. Using DNSSEC, BG- 
PSEC, and TLS, we measured the latency of the total page 
loading time, which included blocking of the connection re¬ 
quest, the DNS lookup, the connect, send, and wait, and re¬ 
ceive times, and the TLS handshake. The observed latencies 
ranged from 15 ms to 7 969 ms, with an average of 534 ms 
and a median of 1 811 ms. Eor SAINT, we assumed that 
a path lookup has an equivalent latency to a DNS query 
(one round trip), fast cryptography is used in verification 
(ed25519), and an average of 8 keys are authenticated during 
the DNS and routing lookups. In this setting, we observed 
latencies ranging from 19 ms to 7 974 ms, with an average 
of 586 ms and a median of 1 863 ms. These latencies are 
not based on a full deployment of SAINT, but indicate a rea¬ 
sonable 10% increase in connection latency on average as 
compared to the current Internet. 


11. DEPLOYING SAINT 

We now discuss several deployment challenges for SAINT 
and propose several solutions to facilitate the deployment 
of SAINT in the current Internet. Specifically, we discuss 
saint’s interoperability with the current Internet, and de¬ 
scribe how ISDs can be initially deployed. We then propose 
a method for the initial distribution of TRC files. 

The Legacy ISD. To facilitate the incremental deployment 
of SAINT, we propose a special ISD called the legacy ISD 
C, which represents the set of all domains that have not 
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yet joined a SAINT ISD. For example, suppose that a. com 
maps to the IP address 1.2.3.4 in the current Internet, which 
is located in AS 567, which has not yet deployed SAINT. 

The domain a.com would then correspond to the address 
(£,567,1.2.3.4). The security guarantees for names, routes, 
and EE certificates in the legacy ISD are only as strong as 
they are in today’s Internet. 

One challenge we face in practice is that names in S AINT’s 
generic TLDs may already exist in the legacy ISD. Not only 
do such collisions cause a problem for name resolution, but 
they also create vulnerabilities to downgrade attacks in S AINT’s 
name lookup mechanism, since an adversary could simply 
return an unsecured DNS response in the legacy ISD for a 
query with a name collision. We therefore require SAINT 
name resolvers to query the legacy ISD as a last resort, and 
only with a proof of the name’s absence in the SAINT names¬ 
pace (such as an NSEC3 record). 

Interoperability. SAINT is designed with a focus on incre¬ 
mental deployability. ISDs can be deployed among individ¬ 
ual networks, since the remainder of the Internet that has not 
yet deployed SAINT joins the the legacy ISD. The naming 
infrastructure is interoperable with that of the current Inter¬ 
net in that it can query the legacy DNS nameservers as is 
done today. Routing between two physically separated do¬ 
mains in SCION can utilize IP tunneling to communicate 
over the legacy ISD. 

In order to maintain connectivity to the current Internet, 
servers and clients must support legacy authentication. In 
particular, clients and servers must continue to support DNSSEC, 
BGPSEC, and TLS. Additionally, when servers receive in¬ 
coming connections from the legacy ISD, they should not 
respond with SAINT-specihc messages such as signed path 
sets or cross-signing certificates. However, TRC hies will 
be made available through the legacy ISD in order to sup¬ 
port the initial bootstrapping of trust roots. 

ISD Deployment. SAINT offers benehts even for early de- 
ployers of ISDs. A single-ISD deployment of SAINT pro¬ 
vides isolation of compromises within that ISD. Addition¬ 
ally, the legacy ISD will be protected from compromised 
trust roots in every ISD deploying SAINT. Moreover, ISDs 
deploying SAINT enjoy greater hexibility in their choice of 
alternative PKIs by enabling the benehts of the PKIs without 
requiring their global deployment. In the policy held of the 
TRC hie, an ISD would specify its choice of the underlying 
PKI, which would prevent protocol downgrade attacks. 

If using countries as ISDs, then a newly-deploying ISD 
can simply attach to the existing namespace at its corre¬ 
sponding ccTLD. This construction allows the DNS to pro¬ 
vide a scaffolding during the deployment of SAINT and also 
allows the DNS in SAINT to distribute TRC hies. 

However, we recognize the challenges that come with us¬ 
ing countries as ISDs. In particular, the deployment of such 
a scheme would require the core ISPs, root CAs, and Inter¬ 
net registries in each country to create a federation of trust 
roots. In practice, we may see corporations rather than coun¬ 


tries form ISDs. In this case, ISDs would have to form IP 
tunnels in order to form inter-ISD routing relationships. Ad¬ 
ditionally, since there are far more corporations than coun¬ 
tries, cross-signing relationships may not scale to this num¬ 
ber of ISDs. However, because most corporations do not 
form many business relationships relative to the number of 
corporations that exist, we do not expect that the number 
of cross-signing relationships will grow to an unsustainable 
scale. 

TRC Distribution. The initial distribution of TRCs must 
occur securely since TRCs are the starting point for all au¬ 
thentication in SAINT. Many trust roots in the current In¬ 
ternet may continue to serve as trust roots in SAINT, and 
thus may be able to “inherit” user trust in SAINT that they 
already have in the current Internet. However, SAINT will 
likely result in the creation of new trust roots, and thus must 
have a mechanism for bootstrapping trust in the initial public 
keys of these roots. 

To address this challenge, we suggest to perform the initial 
distribution of SAINT TRC hies through DNSSEC. Since 
ISDs can deploy by attaching to specihc ccTLDs in the cur¬ 
rent DNS namespace, an ISD can create a reserved domain 
name such as trc. us, whose DNS record contains the TRC 
(e.g., in a TXT record). Clients can then fetch the TRC 
by looking up the appropriate domain name. Additional 
work has been done in distributing authentication informa¬ 
tion through out-of-band means such as over public radio p^ , 
but these strategies are beyond the scope of this paper. 


12. DISCUSSION 


Feasibility of country-based ISDs. In order to determine 
the feasibility of having countries as ISDs in SAINT as de¬ 
scribed in Section 4.1 we mapped AS numbers to countries 
and examined the resulting inter-ISD relationships. We used 
the AS relationships database from CAIDA Q and Team 
Cymru’s IP to AS number mapping toolj^to map AS num¬ 
bers to countries. We identihed 228 “countries” in total, 
including the EU and ZZ (indicating that the AS’s country 
was unknown). We identified 2 636 unique country pairs be¬ 
tween which an inter-AS link existed. These links signify 
direct routing connections, and thus we expect cross-signing 
for each ISD pair. The most prolihc cross-signing ISDs were 
the US (196), the EU (135), and the UK (124), but half of 
the ISDs cross-sign on the order of tens of other ISDs. 


Political Concerns. Given concerns over governmental nation¬ 
wide surveillance, readers may worry about centralizing trust 
roots in a large ISD. While we acknowledge that states may 
compromise these entities on a large scale, SAINT’s trust 
agility allows users to protect themselves from the inter¬ 
ception of sensitive connections. Additionally, our efficient 
method of updating trust root information allows ISDs to 
quickly recover from a compromised CA. 

'^http://www. team-cymru.org/Services/ip-to-asn.html 
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Another concern we anticipate is that SAINT encourages 
fragmentation in the Internet. While this is true, SAINT 
is designed to preserve global reachability while simulta¬ 
neously protecting users through the use of ISDs and triist 
agility. We thus structure inter-ISD authentication to pro¬ 
vide users with the best of both worlds. 


Sub-ISDs. To add further scalability to SAINT, we propose 
the use of sub-ISDs, i.e., ISDs being completely contained 
in other ISDs. A sub-ISD can be used to provide additional 
policies and finer-grained control of trust roots in an ISD, 
and can additionally enable isolated authentication within 
an ISD. For example, governments or medical organizations 
may use their own network within a country ISD to ensure 
data privacy and further scope the authority of their trTist 
roots. 

A sub-ISD structurally resembles a top-level ISD, but au¬ 
thenticates to other sub-ISDs in the same parent ISD using 
the core of the parent ISD, and has its trust roots of a cer¬ 
tified by its parent ISD via a cross-signing certificate. Con¬ 
nections within an ISD could then be negotiated using the 
lowest-level common ISD. For example, two hospitals in an 
ISD would share data about a patient using the medical sub- 
ISD rather than the general ISD. 

Some details regarding authentication for sub-ISDs still 
remain, however. For example, compromised trust roots could 
also affect authentication entirely within a sub-ISD due to 
the requirement that parent ISDs certify the trust roots of 
their sub-ISDs. Furthermore, users cannot select sub-ISDs 
as their trust anchor ISDs without also trusting the corte- 
sponding parent ISDs. We hope to investigate these chal¬ 
lenges in future work. 


Optimizations. As described in Section 9 the authentica¬ 
tion process involves six round-trip connections from Alice. 
Each communication with the path server requires verifica¬ 
tion of the path server’s signature, the signed set of routing 
paths returned by the path server, the destination AS cer¬ 
tificate, and possibly cross-signing certificates for the path 
server and destination AS’s ISDs. To contact a destination 
outside her trust anchor ISD, Alice must also obtain and ver¬ 
ify a cross-signing certificate. Contacting the DNS server re¬ 
quires verification of at least the DNS root key, server DNS 
key, and signed DNS record, and contacting the server (Bob) 
requires verification of at least the server certificate. 

However, in practice many of these verifications may not 
be necessary. Caching cross-signing certificates, for exam¬ 
ple, eliminates the need to reach a TRC server and to verify a 
cross-signing certificate with each end-to-end connection es¬ 
tablishment. Additionally, some of these verifications can be 
handled by entities other than the client; for example, paths 
can be verified by the client’s AS, and DNS records by a 
trusted DNS stub resolver. Since ASes and stub resolvers 
serve multiple clients, caching verification results can fur¬ 
ther reduce the connection latency, especially for popular 
names, routes, and EE certificates. 

In order to further decrease the size of messages sent in 


the network, we can also split the TRC file into routing and a 
service TRC files. The routing TRC can then be propagated 
along AS links, and the service TRC can be obtained from 
the TRC server. This scheme ensures that users only receive 
the portion of the TRC that they need for a particular type 
of authentication, thus reducing the size of TRC files sent in 
the network. 


13. RELATED WORK 

This section provides related work supplemental to the work 
mentioned in Section 2 Many such works propose mech¬ 
anisms to authenticate network entities. We review these 
works with regards to domain-centric proposals as well as 
authentication for naming, routing, and EE certification. 


Domain-centric proposals. The idea of aggregating hosts 
and routers into an abstracted routing entity has been previ¬ 
ously proposed. The Nimrod routing architecture O) de¬ 
scribes a hierarchy of “clusters” of hosts, routers, or net¬ 
works that can reach each other via a path contained within 
the cluster. EARA generalizes the notion of an “entity” 
to also include clusters of computers that can be reached as 
a network communication endpoint. ISDs in SAINT fit the 
criteria for clusters in Nimrod, but add a set of common trTist 
roots as well as the constraint that all intra-domain paths 
must be contained within the ISD. 


Name authentication. Previous work has addressed au¬ 
thentication in a distributed, large scale network without any 
global trust infrastructure. Birrell et al. 0 propose to use an 
authenticated path through the name space to make explicit 
trust relationships among entities, and Lampson et al. | [25] 
describe an authentication theory based on the name space 
or the communication channel from which the other entity’s 
authority can be deduced. Gligor et al. define a policy 
for inter-realm authentication trust based on trust hierarchies 
that can support transparent name authentication. 


Routing authentication. AIP 0 provides accountability 
for network entities based on self-certifying names, where 
the name of an entity is its public key |33-35 391. AIP 
groups an independent administrative network into an ac¬ 
countability domain (AD) and assigned globally unique self- 
certifying names to ADs and hosts. Consequently, at the AD 
granularity, AIP not only supports routing and forwarding 
authentication, but also domain authentication without rely¬ 
ing on an external PKI. However, key discovery in AIP re¬ 
lies on DNSSEC, and key revocations always force entities 
to change their names. 

IPA p0[ focuses on incremental deployment in the current 
Internet and leverages DNSSEC as a lightweight PKI to en¬ 
able host authentication. IPA distributes AS certificates via 
S-BGP routing update messages, avoiding circular depen¬ 
dencies. However, it relies in a single global root of trust. 


End-entity authentication. Several proposals raise issues 
with the current domain authentication schemes based on 
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X.509 and propose enhancements. For example, CAge p2) 
proposes to restrict CAs to signing domains in a small num¬ 
ber of TLDs and treat other certihcates as suspicious, and 
the US government has also recently considered this pro¬ 
posal 0 - Abadi et al. suggest a policy engine to empower 
clients or ISPs to specify acceptance criteria for certihcates Q 
Although the authors outline a promising user-oriented en¬ 
tity authentication policy, its integration in the end-user sys¬ 
tem is still in question. 

DANE leverages the DNSSEC infrastructure to au¬ 
thenticate TLS public keys. Its goals are to tie TLS public 
keys to DNS names, use DNS to distribute these public keys, 
and to leverage the hierarchical authentication structure of 
DNSSEC to restrict the scope of CAs’ authority. However, 
the security of DANE relies on the security of DNSSEC. A 
compromised DNSSEC key can be used to specify arbitrary 
trust anchors and bypass X.509 certihcate validation. 

Certihcate Transparency (CT) | [26| and the Accountable 
Key Infrastructure (AKI) p4) expose all CA operations to 
the public to improve the security of SSL/TLS PKIs. Neither 
CT nor AKI dehne how misbehavior should be disseminated 
to users and other parties, but both can be deployed in ISDs, 
which leverage TRC hies to quickly remove a compromised 
trust root and update users’ trust root information. 

14. CONCLUSIONS 

By explicitly separating and scoping trusted authorities in 
the Internet, we allow users to choose their trust roots and 
protect users from compromises throughout the Internet. By 
distributing trust root information as network messages, we 
allow users to quickly obtain up-to-date information about 
compromised or updated trust roots. By mandating cross¬ 
signing relationships based on routing connections, we en¬ 
sure that users can authenticate information throughout the 
Internet. By separating routing and service authentication, 
we allow users’ trust root decisions to apply anywhere in 
the world. These ideas address fundamental shortcomings 
of current authentication and secure Alice’s communications 
throughout the world regardless of her choice of trust roots. 
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APPENDIX 

DNS Resolution for Generic TLDs 

As stated in |Section 5.2[ for reasons of transparency and security, 
each domain name with a generic TLD is resolved to a regional 
domain name (rather than to an address). Assume, for example, a 
company r wants to register the domain r. com. Instead of regis¬ 
tering a DNS tuple (r .com, IP), the company registers one or more 
CNAME-like record^that point to other (usually regional) domain 
names: 

r.com —>■ {r.us, r.de, r-swiss.ch, r-italia.it} (1) 

Upon a DNS resolution request for a generic domain D from a 
client, the DNS server for . com returns all regional names for D 
in the order specified by the registrant r. The client then either 
chooses a domain name that is within its own ISD, or it chooses 
any other domain name in the provided list. 

^CNAME records cannot point to multiple names, but the general 
idea of our records is the same. 


In order to ensure the authenticity of generic DNS records, SAINT 
requires a minimal setup as follows: any registrant r must first reg¬ 
ister its DNS public key DKr with the generic DNS server S. 

DKr „ . , 

r - > 5 C.com; 

S stores and signs the public key DKr, and returns the signature 
{r,DKr}^-u 

r i - - - S ( . com) 


After this initial step, registrant r registers its domain name D by 
providing the list of regional domain names {...} together with a 
signature {D, {.. . 


r 


{D.{...}} 


■> S ( . com) 


Verification. This domain-specific signature is verified whenever 
a client c wants to authenticate a DNS response for a generic do¬ 
main D. 

D'> 

c -^->■ S ( . com) 

{D.{...}} {D.{...}}^^_1 DKr {r,DKr}^-i 

< - ^- - - 

The client verifies the signature {r,DKr} and caches the public 

verification key DKr of the registrant r of domain D. The client 
then verifies the authenticity of the record {D,{. ..}} using the reg¬ 
istrant’s public key DKr. 

If the verification was successful, the client choses one of the 
specified regional domain names and resolves its actual address 
(I,A,E). 

Performance. As in the current DNSSEC, the DNS server S for 
generic TLDs does not sign the stored CNAME-like records itself; 
rather, it signs the public keys of the registrants. The reasons in¬ 
clude performance considerations: whenever a registrant r wants 
to register a new generic domain or whenever r wants to extend 
an existing record, the DNS server has minimal effort in that it 
does not need to validate or sign the new records. Using CNAME- 
like records also keeps the performance close to existing lookups: 
CNAME records add only 13% latency to a DNS name resolution 
on average|^ 

Availability. Whenever a client needs to resolve a generic domain 
name, the client first contacts its local DNS server. If the local 
DNS server has no cached entry for the generic domain, the re¬ 
quest is redirected to the DNS server of the generic TLD. This one 
step of indirection is at least as robust as today’s DNS system: in 
case the DNS server for a generic domain is unavailable, then only 
the availability of that single TLD is constricted. There is hence no 
single point of failure for the entire DNS system. As today, caching 
of generic domain name records by local DNS servers further in¬ 
creases the robustness and performance for generic DNS lookups. 

Security. The record for a generic domain D is signed by the owner 
of D (i.e., the registrant r) using an asymmetric signature scheme 
and the private signing key of r. The public verification key of r is 
signed by r’s ISD and by the DNS server for . com. Client C can 
hence base its trust on the ISD of r or (in case C does not trust this 
ISD) on the DNS server for . com. 

Another positive aspect of this design is the fact that a key com¬ 
promise of . corn’s DNS server does not directly affect the security 
of an end-to-end connection: an attacker would additionally need to 

®This result is based on our private discussions with Verisign Labs. 
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compromise the DNS server of a regional ISD, which is used for the 
second lookup, the regional lookup for the actual address {T,A,E). 
Despite being unlikely, this attack only works under the assump¬ 
tion that a client uses the verification key of . com (rather than the 
verification key of the resolved regional CNAME domain). 
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